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ABSTRACT: 

A directory dabatase system includes a network and a plurality of directory service units (DSU). 
each of the DSUs providing one or more directory service functions within the directory database. 
For propagation of an undirected user query relative to an object in the database from a source 
DSU to one or more target DSUs, one of which may contain information relative to the object, a 
propagation (P) table is provided in each of the DSUs^ the P tables being a data structure 
capable of determining which other DSUs to send the user query to. The source DSU examines 
its associated P table for the directory type specified in the query to generate an identification of 
one or more additional target ones of the DSUs to which the query should be directed. After 
propagating a query from the source DSU to those additional DSUs identified by the P table in 
the source DSU, there is returned to the source DSU information responsive to the user query 
from the one of the additional target DSUs containing the information. 
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® A directory dabatase system includes a network 
and a plurality of directory service units (DSU). each 
of the DSUs providing one or more directory service 
functions within the directory database. For propaga- 
tion of an undirected user query relative to an object 

2!*n the database from a source DSU to one or more 
target DSUs, one of which may contain information 

IS relative to the object, a propagation (P) table Is 
provided in each of the DSUs. the P tables being a 
data structure capable of determining which other 

WdSUs to send the user query to. 

1^ The source DSU examin s its associated P tabi 
f r the directory type sp cifi d In the qu ry to g n- 

®erate an Identification of on or mor additional 
target ones of th DSUs to which the query should 

lUbe directed. Aft r propagating a query from th 
source DSU to those additional DSUs identified by 
the P table in the source DSU. ther is returned to 
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PROPAGATION APPARATUS FOR NETWORK QUERIES THROUGH SUPERIOR-SUBORDINATE AND PEER- 

PEER DATA DISTRIBUTION RELATIONSHIPS 



CROSS-REFERENCE TO RELATED APPLICA- 
TIONS 

The following copending applications, all filed 
* by the same assignee as the present application, 
are related to the subject matter of this application, 
in that, they each relate, to different aspects of a 
directory database system. 

(A1) "Generalized Data Directory Model". 
Application N"" 

(A2) "Generalized Algorithmic Control Blocks 
for Sequential and Parallel Queries in Distributed 
Directory Networlcs". Application N** 

(A3) "Dynamic Update of Database Direc- 
tories Using Directed or Undirected Mechanisms", 
Application N** 

(A4) "Hybrid Directory Data Distribution 
Schemes for Network Topok)gies", Application N** 

All of these applications (filed concurrently with 
the present application) are incorporated herein by 
reference. 



BACKGROUND OF THE INVENTION 
Field of the invention 



Description of the Prior Art 

Distributed database management systems of- 
fer users the ability to distribute data and workload 
5 among multiple processing sites. Ideally, a distrib- 
uted database management system should support 
growth while preserving local administrative auton- 
omy and control of access to k)caily stored data. At 
the same time, the distributed database should 
70 provide Its users with a single system image such 
that, although the data is distributed among several 
sites, the data distribution is transparent to the 
users who express their database accesses as 
though the data is at one place. 
75 It is important to preserve the local autonomy 

of database administrators and users at each site 
of the distributed database while, at the same time, 
supporting information sharing among sites. It is to 
be expected that the equipment supporting the 
20 database at different sites will be controlled by 
different administrative entities. This expectation in- 
creases as the entry costs for computing facilities 
decline. Increased distribution of computing facili- 
ties leads to additional requirements for information 
25 sharing between sites to suppwrt the shared objec- 
tives and interests of the users at different sitesr 
Therefore, credible access control mechanisms 
must be provided to insure isolation, when desired, 
and to control access to the shared InfonDation. At 
the same time, users must be able to easily access 
and manipulate remote data as though it were 
local- 

The distiibuted database management system 
architecture should preserve local control and func- 
tion when accessing local database objects. The 
iasA that a site participates in the distributed 
database should not reduce that site's ability to 
perfonm local actions on kx:al data by requiring the 
participation of other sites. Also, data access avail- 
ability should be a function only of the availability 
of the site(s) storing that data objects. The failure 
of one site should not impact sites which do not 
reference database objects stored (or controlled) 
by the failed site. 

Rnally, it must not t>e difficult for an existing 
database site to join the distributed database. It 
should be fairiy easy for an existing database site 
to establish the ability to access data at another 
site. The addition of another site to the distributed 
databas must not require a nationwide (or global) 
syst m generation. 



This invention relates to systems for propaga- 30 
Hon user queries through a database networic tiie 
system being independent of the networi< topology. 
In the present application the term "directory" 
means a table of names and corresponding items 
of data. Data In a directory is locational or directive ds 
In nature. e.g. 

(1) a listing of names, addresses, and other 
data about a specific group of persons or organisa- 
tions, or 

(2) an index that is used by a control pro- 40 
grarri to locate one or more bkx:ks of data stored in 
separate areas of a data set in direct access stor- 
age, or 

(3) an index to locate blocks of program in- 
formation. The user of a directory knows the defini- 4s 
tion of the object references by a name, but needs 
the specific data value(s). e.g. phone numk>er, in 
order to perform a specific activity. 
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U.S. Patent 4.468.728 discloses data structure 
and a search m thod for a database management 
system in which the data structure is arranged In a 
plurality of search trees. The initial search tree and 
an initial subset of trees are maintained in a main 
fast access memory, while the remaining trees are 
kept in mass memory. An input search parameter 
is partitioned into a plurality of subparameters, one 
for each search tree. The subparameters are used 
to search a tree in each level of the data structure 
until the location of a terminating file Is determined. 

An article entitled "Object Naming and Catalog 
Management For a Distributed Database Manager". 
Lindsay. 1981 IEEE, page 31, describes a system 
in which distribution of the catalog representation 
and maintenance leads to an architecture which 
supports transparent user access to data which 
may be distributed, replicated; and partitioned 
among the site of the distributed system. The ar- 
chitecture preserves individual site autonomy while 
facilitating graceful system growth. 



SUMMARY OF THE INVENTION 

The ' requirements placed upon the query 
mechanism, provide the rationale for the mecha- 
nisms themselves. The requirements are as fol- 
lows: 

1. Full Accessibility: This is the basic re- 
quirement It states that if a piece of information Is 
stored in the directory services system, a user at 
any DSU in the system sbouid be able to gain 
access to that Infonmation. This should be possible 
even if the user does not know precisely where that 
information is stored, or the way in which data is 
distributed through DSS. The requirement is sub- 
ject to several exceptions such as security or ac- 
cess control restrictions. However. In general, the 
design of the query mechanisms is be primarily 
driven by this requirement. 

SLSubset-Abillty: This requirement states that 
all DSUs participating In a DSS need not imple- 
ment the full function of the query mechanism in 
order for the first requirement to be satisfied. For 
example, small wori< stations in a DSS may not 
wish to act as an Intermediate node in query prop- 
agation, but the users of the DSS may still require 
full accessibility. Implied in this requirement is the 
necessity for compatibility between different sub- 
sets operating within the same DSS. 

3.Performance: Performance can be mea- 
sured in many different ways. The major perfor- 
mance criteria are: 

a. Bandwidth: It is clearly desirable to 
minimize tiie number of messages s nt through th 
network by the query mechanisms, thereby freeing 
network bandwidth for other purposes. 



b. Storage: Minimizing storage is particu- 
lariy important in environments which consist of 
small minicomputers and/or work stations. 

c. Delay: This ref rs in particular to query 
5 response times. 

The algorithms employed in the present inven- 
tion are designed, as far as possible, to minimize 
the above criteria 

70 

BRIEF DESCRIPTION OF THE DRAWINGS 

Rg.1 is a block diagram illustrating pro- 
cesses using a directory service system; 
IS Rg. 2 IS a block diagram illustrating intercon- 

nected DSUs in a DSS; 

Rg. 3 illustrates the processing functions 
distributed In a DSS: 

Rg. 4 illustrates a two-level hybrid directory 
20 system; 

Rg. 5 shows the structure of the end user 
service P(U); 

Rg. 6 is a block diagram Illustrating the 
structure of the directory function service P(F); 
25 Rg. 7 is a block diagram showing the stmc- 

ture of the directory data service P(D); 

Rg. 8 illustrates tiie stmcture of tiie network 
service process P(N); 

Rg. 9 shows the distribution of directory 
30 service processes In a DSS; 

Rg. 10 illustrates DSI request flows among 

DSPs: 

Rg. 11 illustrates the reply flows among 

DSPs; 

35 Rg. 12 Is a block diagram of the overall 

structure of the system of the present invention; 

Rgs. 13 and 14 illustrate the processing 
sequences for update and query propagation, re- 
spectively, in accordance with the present inven- 

40 tion; 

Rg. 15 is a representation of a typical direc- 
tory operation control block; 

Rg. 16 shows the flow of a directed query in 
accordance with the present invention; 
45 Rg. 17 illustrates tiie flow where a special 

directory is queried to obta'n a target DSU Iden- 
tification for a directed query; 

Rg. 18 shows the propagation of an un- 
directed query; 
50 Rg. 19 illustrates an example of undesired 

looping between two DSUs during a query; 

Rg. 20 shows a representative query P-table 
. (OP) and au update P-tabie (UP); 

Rg. 21 is a pictorial representation of a 
55 Superior-Subordinate (SUP-SUB) -r lationship be- 
tween DSUs; 

Rg. 22 illustrates the flow for P-table transla- 
tion for tiie SUP-SUB relationship shown in Rg. 21; 
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Rg. 23 is a representation of DSUs having a 
Peer-Peer relationship to each other; 

Rg. 24 shows the P-table translation for th 
DSUs of Rg. 23; 

Rg. 25 is a repr sentation of DSUs having a s 
Replicated relationship to each othen 

Rg. 26 shows the P-table translation for the 
DSUs of Rg. 25; 

Rgs. 27-30 illustrate a number of other rela- 
tionships among other DSUs; ro 

Rg. 31 shows a UP-table illustrating parallel 
propagation to a number of SUP DSUs; 

Rg. 32 shows a QP-table for the parallel 
propagation to SUP and PEER DSUs; 

Rg. 33 shows a QP-table for the parallel ts 
propagation between SUP and PEER DSUs; 

Rg. 34 illustrates a typical query message 
propagated in accordance with the present inven- 
tion; and 

Rg. 35 shows a typical response to a query. 20 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENT 

25 

In the description and drawings, the following 
terms are used with the indicated ineanings. 

Application Interface (API) -The protocol 
boundary between the user and the directory ser- 
vice. 30 

Directory Service interface (DSh -The internal 
interface between directory service units and out- 
side services, such as communication, user ser- 
vices, or user data areas. 

Directory Service System (DSS) -An Instance ss 
of directory service in a given network of distrib- 
uted directory services. 

Directory Service IJnji (DSUV -Au unit of DSS 
that provides one or more directory service^ func- 
tions. 40 

Prior to a detailed description of the present 
invention, the following overview of the environment 
and elements of the Invention are given. 

The basic stiucture of the directory database 
system of the present invention in shown in Rg. 45 
12. Rg. 12 illustrates the different interfaces or 
protocol boundaries between the DSU shown in the 
dotted enclosure and other portions ot the system. 
Theses boundaries include a user protocol bound- 
ary shown at the top of the figure, a data access 50 
protocol boundary at the right side of the figure 
representing the interface between the DSU and 
the database, and a communications protocol 
boundary illustrated at tii bottom of th figure. 



Th pros nt structure and method is based on 
a distribution schem wher an instance of direc- 
tory s rvic may include on or mor DSUs. Each 
DSU may perform one or more dir ctory functions 
depending upon the product implementation. 

The directory service system (DSS) shown in 
Figure 1 is an installation of directory functions In a 
network of interconnected system. DSS provides 
the architectural directory services for the user at 
the API protocol boundary. The participating sys- 
tems (products) in a DSS operate coherentiy under 
the architected rules such as data distribution - 
schemes, naming schemes, search/update algo- 
rithms, error recovery, synchronization and the like. 

A DSS is comprised of a collection of directory 
service units distributed troughout the intercon- 
nected system network as shown in Rgure 2. A 
DSU represents the directory service component of 
a system product implementing directory service 
functions. Afthough multiple DSUs may exist In the 
same system (product) for different applications, it 
is the intent that a single DSU can support many 
applications programs to eliminate duplication. 

DSU. Functions 

A DSU is composed of a set of functional 
components called directory service processes - 
(DSP) to provide the subsetting basis for imple- 
mentation by products. There are the following four 
types of DSPs, each of which performs distinct 
functions. 

1. User Service Process, denoted as P(U) or 
U, manages the interface (protocol boundary) with 
users. 

2. Directory Function Process, denoted as P- 
(F) or F. processes the directory functions to ser- 
vice the directory request using the algorithms 
(query/update/naming). 

3. Directory Data Service, denoted as P(D) 
or D. manages the access and maintenance of the 
directory data. 

4. Network . Service Process, denoted as P- 
(N) or N, manages the transport network facilities to 
communicate with other DSUs. 

In order to obtain full directory service, it is not 
necessary that every DSU in the system implement 
all DSPs. For example, a work-station may imple- 
ment only some of the functions and obtain full 
directory service through interaction with a larger 
system product Thus, a DSU may contain all four 
DSPs or some of the DSPs as necessary to meet 
til functional needs of each product, 

Rgur 3 shows an xample of impi m ntation 
options by products in a simpi n twork. DSU A 
and DSU D repres nt th worit-station which per- 
forms tiie qu ry on an as needed basis and dls- 
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cards the results of the query without retaining it in 
the storage. This typ of product may not have to 
implement P(D). DSU C represents another type of 
work-station which retains the results of a query in 
its local directory. This type of product needs to s 
implement P(D). DSU B represents the file server 
which acts merely as a data repository to maintain 
the master directory for the network. This type of 
product may not have to implement P(U). 



DSU Roles 

In order to perform a directory service in a 
distributed network environment, several DSUs are 75 
generally involved and each DSU plays different 
roles. The origin or source DSU receives a direc- 
tory request firom the user and originates the DSI 
request. The request is propagated through the 
intermediate DSUs as necessary to reach the tar- 20 
get DSU which can service the request. 



Directory Data Base 

25 

A directory is a database that stores mappings 
from name to information related to name. The 
directory data base is a set of directories which 
contain information of a similar type. There is more 
than one member in the set If the directory data . 30 
base is distributed across participating DSUs. The 
directory data base and all members which com- 
prise it are named via a directory type ID (Directory 
Identifier). For example, a directory database with 
directory type_ID TELEPHONE may contain name 35 
to telephone number mappings. A single DSU may 
maintain directories of different directory 
type__iP's, but for any given type_ID, a DSU may 
contain at most one directory. 



Directory Distribution 

Some examples of directory distribution 
schemes are as follows: 45 



Centralized Directory System 

In this centralize directory system, there is a so 
single master directory per directory type-ID lo- 
cated at one of the DSUs. The master directory will 
be updated whenever a change tak s place. Dir c- 
tory updating in such a system is r latively easy. 
However, there are communication costs (traffic) 55 



incurred for each query, infomnation at each DSU, 
as well as the communication cost for updating ail 
these directories. 



Hybrid Directory System 

For networics up to a few tens of DSUs. a 
single level (primitive) distribution scheme de- 
scribed above (that is, centralized, localized and 
distributed), is usually sufficient. Beyond this num- 
ber of nodes, hybrid systems combining various 
primitive distribution schemes in a hierarchical 
manner, as illustrated in Rgure 4. may be attrac- 
tive. The hybrid multiple level design can offer both 
types of performance improvements over a single 
level design. 

The hybrid directory system is logically divided 
in subsystems, or regions, made up of any number 
of distributed directory services. Each sut)system 
uses different (primitive) directory distribution - 
schemes to fit into its regional environment. The 
hierarchical relationships between subsystems are 
independent of the actual topology of the physical 
network. 



DSU-DSU Relationship 

A directory service can define the functional 
relationship among the DSUs distributed In tiie 
network due to the following aspects: 

The relationship provides a method of organizing 
the DSUs distributed in the network to allow the 
definition of simple and efficient protocols for the 
propagation of DSI commands such as 
query/update. In particular, the relationship can be 
used to constrain the set of DSUs to which a 
particular DSU can send a DSI command for 
queryAjpdate. The relationship is used to control 
how to distribute tiie directories, per directory type, 
among DSUs and how to maintain the respective 
directory. In some of the directory applications, the 
relationship of a particular set of DSUs might re- 
flect tiie organisation structure of the entreprise 
owning the network, even though the networic topol- 
ogy does not. 



DSU-DSU Communication 

Th lines joining the DSUs in Rgure 2 indicate 
th communication patiis. Communication between 
DSUs may be accomplished through the use of 
any one of several different transport mechanisms. 
For example. DSUs may communicate with each 
other by running as a set of transaction models 
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using IBM's. Syst m Network Architecture (SNA) or 
equivalent level of transport facilities. In this case, 
the lines represent s ssions and may not res mble 
in ariy way the physical topology of the network. 
The only assumption that the directroy service 5 
structure makes about the nature of the transport 
mechanism is that it provides guaranteed error-free 
delivery of data from source to destination. 



User DSU Interface 

The user makes a directory function request by 
way of the API verbs to one of the DSUs. The 
•requested DSU interacts with other remote DSUs. 
and then provides the appropriate response to the 
user. 



DIRECTORY SERVICE PROCESS (DSP) 



70 
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20 



This section describes the functions and struc- 
ture of each DSP. In practice, the DSPs may be 
Implemented either in programming or by a micro- 
processor. 25 



End User Service Process P(U) 

The P(U) tjasically manages the protocol 30 
boundary to service the end user request. Only P* 
(U) interfaces with the API. thus shiekjing other 
DSPs from the end user. At the request of the end 
user. P(U) parses the received verbs and sends the 
directory request to P(F) for the 3s 
infonmation/response ponse. When it receives the 
infbrmatton/iiesponse from P(F), it returns it to user 
to satisfy the original API verb. 



Structure of P(U) 

As shown in Rg. 5. P(U) consists of a set of 
API verb processors, each of which has two com- 
ponents (API send processor and API receive pro- 4S 
cessor). The API send processor is to parse the 
API verbs and its associated parameters from the 
user and construct the DSI request encoding to be 
sent to P(F) for specific directory tasks as re- 
quested in the API veriDS, The API receive proces- so 
sor is to decode the received DSI replies and 
present the information/data (carried in the reply) to 
the user protocol boundary according to the de- 
fined API rules. 

55 



Directory Function Service: P{F) 

Th P(F) performs th essence of distributed 
directory functions such as search/update algo- 
rithms and naming algorithm. P(F) is knowledge- 
able of the existence of distributed directories and 
name database (if any), and it provides a focal 
point for maintaining currency among them in the 
system. 

The P(F) is responsible for providing the in- 
formation response satisfying the request from P- 
(U). P(F) maintains/ manages the directory opera- 
tion control block to be used by the directory 
algorithm facilities. The control block contains the 
algorithm control information such as affinity lists. 
P(F) uses this infonmation to detennnine the best 
way to get infonmation and respond to the requests 
from P(U). P{F) interacts with other remote P(F)s as 
necessary to locate the target P(F) (that is. the P- 
(F) directiy linked to the P{D) which can access 
requested directory data). The target P(F) obtains 
the directory data from the D (P), and sends it to 
the source P(F) (that is. the P(F) that originally 
received a request from P(U)). Then the source P- 
(F) passes the directory data to the P(U) that 
originated the request P(F) is the bridge form of 
service interacting with both P(U) and P(D), as well 
as P(N). 



Structure of P(F) 

As shown in Rg 6, P(F) consists of a set of DSI 
command processors, each of which has two com- 
ponents (DSI request processor and DSI reply pro- 
cessor) to process the received requests and re- 
plies respectively. The format of the input to the P- 
(F) shouW preserve the DSI command construct 
regardless of whether the command is received 
from the P(U) or the remote P(F)s through the 
communication network. 

The DSI request processor the DSI processes 
tiie DSI requests received from either P(U) or re- 
mote DSUs. It uses the directory algorithm facilities 
such as the query/update propagation alogorithm 
and the name assignment algorithm as appropriate. 
The directory algorithms detennnine ttie. target DSU 
which can provide the requested information. If the 
receiving DSU is determined to be the target DSU. 
tile DSI request processor fetches ttie requested 
infonmation by way of P(D) and sends tiie DSI 
reply canrying ttiat information to ttie origin DSU. 
Otherwise, the DSI request processor passes tfie 
received request to tiie other DSU as the algorithm 
det miines. based on the affinity lists of tti opera- 
tion control block. 
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Th DSI reply processor processes the DSI 
replies which carry the information request d by 
the DSI requests. If the receiving DSU is the origin 
DSU (which originated th DSI request), the DSI 
reply processor passes it to the local P(U). Other- 5 
wise, it sends the received DSI reply toward the 
origin DSU. 



Directory Data Service: P(D) io 

The Pp) manages the directory data access 
protocol boundary to access and maintain the di- 
rectory data. Only P(D) has knowledge of the struc- 
ture of the directory contents by way of the direc- is 
tory descriptors specified by the users, thus shield- 
ing other DSP's from the directory data structures. 

The P(D) receives the directory data request - 
(query, update and so on) from P(F), performs the 
appropriate operation on the directory data by way 20 
of the data access protocol boundary and responds 
as appropriate to the P(F). it is the responsibility of 
P(F=) to locate the target P(D) (that Is, the P(D) 
maintaining the requested directory data) before 
sending a request to that P(D). 2s 



Structure of P(D) 

As shown in Rg. 7, the P(D) consists of two 30 
processors, Read and Write. The read processor 
services the DSI requests (for example, query), 
from P(F}, which requires reading the directory 
data through the data access protocol boundary, ft 
reads the requested directory data according to the 3S 
directory descriptors and returns the retrieved data 
by way of the appropriate DSI reply to P(F). The 
write processor services the DSI requests (for ex- 
ample, update), from P{F). which requires writing 
the directory data through the data access protocol 40 
boundary. It perfonms the directory data update as 
requested, according to the directory descriptors, 
and retums the results, if necessary, via the appro- 
priate DSI reply. 



Directory Network Service: P(N) 

The P(N) provides the ability to send and re- 
ceive the DSi commands between DSUs. it inter- 50 
faces with the transport mechanism used for DSU- 
DSU communication, thus shielding other DSP's 
from the networking function. P(N) controls the 
network protocol boundaries to achieve th P(F) to 
P(F) conversation betwe n remot DSUs. The con- 55 
tent of DSI request^replies are basically transparent 
to P{N), and the function of P(N) is merely to 
deliver the DSI requests/replies to the remote P(F)- 



's through the networic. Also, the P(N) does not 
determine where to send queries or updates. This 
Is det rmined by th propagation algorithm In the 
P(F). 



Stojcture of P(N) 

As illustrated in Rg. 8, the P(N) consists of two 
processors, send and receive. The send processor 
is to control the sending of data in a DSU-DSU 
communication. The receive processor Is to receive 
data from the DSU-DSU communication. The func- 
tions of these processors have direct dependencies 
on the protocol boundary of the network used for 
DSU-DSU communication. The directory structure 
descrit»es the specific functions of P(N) required to 
use the DSU-DSU transport mechanisms. 



Structure of P(F) 

As shown in Rg. 6. P(F) consists of a set of 
DSI command processors, each of which has two 
components (DSI) request processor and DSI reply 
processor) to process the received requests and 
replies respectively. The fonnat of the input to tiie 
P(F) should preserve the DSI command construct 
regardless of whether the command is received 
from the P(y) or the remote P(F)s tiirough tiie 
communication network. 

The DSI request processor processes the DSI 
requests received from either P(U) or remote 
DSUs. It uses the directory algorithm and the name 
assignment algorithm as appropriate. The directory 
algorithms determine the target DSU which can 
provide tiie requested information. If the receiving 
DSU is detenmined to be the target DSU, tiie DSI 
request processor fetches the requested informa- 
tion by way of P(D) and sends the DSI reply 
canrying that information to tiie origin DSU. Otfier- 
wise, the DSI request processor passes the re- 
ceived request to the ottier DSU as the algorithm 
determines, based on the affinity lists of the opera- 
tion control block. 

The DSI reply processor processes the DSI 
replies which carry the information requested by 
the DSI requests. If the receiving DSU is the origin 
DSU (which originated the DSI request), tiie DSI 
reply processor passes it to the local P(U). Ottier- 
wise, it sends the received DSI reply toward tine 
origin DSU. 
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Directory Data Service: P(D) 

The P(D) manages th directory data acc ss 
protocol boundary to access and maintain the di- 
rectory data. Only P(D) has knowledge of the struc- s 
ture of the directory contents by way of the direc- 
tory descriptors specified by the users, thus shield- 
ing other DSP's from the directory data structures. 

The P(D) receives the directory data request - 
(query, update and so on) from P(F). performs the io 
appropriate communication. The functions of these 
processors have direct dependencies on the pro- 
tocol boundary of the network used for DSU-DSU 
communication. The directory structure descrit>es 
the specific functions of P(N) required to use the 75 
DSU-DSU transport mechanisms. 



Relationshtps Between DSPs 

20 

A DSS can be viewed as a collection of an 
arbitrary number of P(U)s, P(F)s. P{D)s and P(N)s - 
(Rgure 9). A DSU must contain at least a P(F) and 
a P(N). although the levels of complexity of the 
functions to be performed vary depending on the 25 
roles of the DUS within a DSS. DSI commands are 
used as the message units to carry infbnmation 
from one DSP to another. There are two types of 
DSI commands. DSI request dans DSI reply. The 
DSI request is used to carry the specific request 30 
Infonnation to the target DSP, and the DSI reply to 
cany the infonmation/response to the origin DSP. 

Based on the definitions of DSPs discussed 
above, the following relationship can be construct- 
ed to depict the message flows among DSPs -P- ss 
(U), P(F). P(D) and P(N). 

Rgure 10 shows the DSI request flows among 
DSPs, The possible flows are: (1) P(U) -P(F). (2) P- 
(F=) .P(F) by way of P(N)s. and (3) P{F) .P(D). 
Rgure 11 shows the DSI reply flows among DSPs. 40 
The possible flows are: (1) P(D) -P(F), (2) P(F) -P- 
(F).and(3)P(F)-P(U). 



Usage of Protocol Boundaries 45 

Thus, the present system definies one protocol 
boundary for Its users and uses three different 
protocol boundaries to fonmally describe the sys- 
tem structure. A DSU provides the protocol bound- so 
ary for the user to send the directory requests to 
DSU and receive the directory 
information/response from DSU. DSU uses the pro- 
tocol boundary of a communication network to 
communicate with another DSU in another syst m. 55 
Another protocol boundary is used by DSU to 



control access s to and read and write the data in 
a directory data model. Th functions of these 
verbs may be implem nted in a product unique 
mann r. i 

In connection with Rgs. 13 and 14 Illustrating 
the processing sequence for update and query 
propogation. respectively, there are separate pro- 
cessors shown for update reply, update request, 
query reply and query request. However, if a given 
DSU is not involved in query propagation, only the 
update processors are required. 

As shown in Rg, 15. the present invention 
employs a directory operation control block. The 
operation control block contains informations which 
controls the directory system functions performed 
on behalf of the user. This component includes 
search (query) algorithm control infomiation. and 
internal tables which define the relationship of this 
member user directory with other members (at 
other DSUs) within a particular directory database. 

The directory operation control block shown in 
Rg. 15 supports directory system services such as 
automatic search and automatic maintenance to the 
user. This control block is associated with a par- 
ticular rnember of the directory database, and the 
informatk)n contained therein is location-dependent. 
This control block is usually initialized by way of 
directory system generation parameters, although 
changes to internal operation of the directory sys- 
tem fo this member may occur dynamically 
through the protocol boundary. 

The directory operation control block contains 
the affinity list, search algorithm contnDl field. Integ- 
rity parameters field, and access control field, 
which can be described as follows. 

Affinity LJst: The affinity list describes the logi- 
cal relationship between this member and other 
members of a particular directory database. The 
affinity list data values describe whether other di- 
rectory database members are superiors, peers, or 
subordinates to this member. The manner in which 
directory data Is distributed, and logically config- 
ured, can therefore be derived firom affinity list data 
values. A consequence of affinity list design en- 
ables a reconfiguration of user data (say. from a 
centralized to a distributed configuration) by subse- 
quent changes to affinity list data values. 



Search Algorithm Control 

This field supports various user options of tiie 
automatic name resolution function. Such options 
may include action to be taken by th DSU upon 
determining a "not found" condition at this m m- 
ber. such as report an " rror". continue searching 
using internal search algorithms, or r turn a data 
value to th us r. 
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There may be cases where a cascaded search 
is possible using participating members' affinitiy 
tables. Simifarly, some members who do not sup- 
port this capability can terminate the search from 
continuing beyond this point; this may be useful to 
support products of varying capabilities in a depth- 
first search algorithm. 



Integrity Parameters 

Degrees of error tolerance, or of consistency of 
user data within the distributed directory database, 
are supported by means of the integrity parameters 
field. These can be described by the user at im- 
plementation. 



The User-DSU Interface 

The protocol boundary verbs (API) used in the 
query functions may include the following which 
are described In rough functional form. The de- 
scription is meant only to provide sufficient detail to 
enable the understanding of the query mechanisms 
that will be described subsequently, and is not in 
any sense meant to be exhaustive. 

The parameters that can be specified for a 
query request include the following: 

Input Search Argument {typically, the name of the 
object) Directory Type ID 

Information Desired 

Whether the query is to fc)e local only. 

There are two basic ways the query mecha- 
nisms can be described; directed and undirected. 



THE DIRECTED QUERY MECHANISM 

This is the simplest query mechanism, and in it 
the user specifies the identity of the DSU to which 
the query message muste be sent-the target DSU. 
The DSU to which the user is attached (the source 
DSU) would then use the transport mechanism to 
send a message to the target DSU. The target DSU 
would receive this message, perform the necessary 
operations on its local directory and respond as 
appropriate. The target DSU would not propagate 
the message to any further remote DSU. 

Figure 16 depicts an example of the use of a 
directed query. It wille be noted that the use of a 
directed query does not imply physical adjacency 
of source DSU and target DSU. Th mechanism 
can be used where the user knows the target DSU 
and the underiying transport provides a commu- 



nication path to the target DSU. The mechanism 
cannot be used if either of the above conditions are 
not satisfied. While the second condition may be 
satisfied in many environments, it is probably un- 
5 lii<ely that the user will know the identity of the 
target DSU. Special' cases where the user has this 
Information may include: 

1. The user obtains this information through 
some mechanism defined by the user. An example 

10 of this mode of operation is if the name of the 
object contains the identity of the target DSU. 

2. A directory service can maintain a special 
directory which contains the identities of tfie target 
DSUs for certain objects in the network! The user 

75 would query this special directory, obtain the target 
DSU information, and then initiate a directed query. 
This special directory may also be maintained 
through one of the query/update mechanisms. Rg- 
ure 17 depicts an example of the use of this 

20 special directory. 

If either condition described above does not 
prevail, or if it desired that target DSUs propagate 
the query further, the directed mechanism cannot 
be employed. 

25 

THE UNDIRECTED QUERY MECHANISM 

in the undirected mechanism, the user does 

30 not provide the identity of the target DSU. Instead, 
the propagation of queries is guided by data struc- 
tures, known as propagation tables or P-tables. 
Each DSU maintains, for each directory type, a P- 
table which determines, for that directory type. 

35 which other DSUs to send query messages to. 

Upon receipt of an undirected query, the 
source DSU consults its P-table for that directory 
type and, based on the information contained in the 
P-tables, sends a. query message to one or more 

40 DSUs. The DSUs that receive the message consult 
their own P-table and may propagate the query 
further. Rgure 18 depicts a typical example of this 
type of query propagation. ^ 

The fact that the receiving DSU may propagate 

45 the message further creates two possible causes of 
Incorrect operation. Rrstly, there is the possibility 
that the query sent to one DSU, (DSU B in the 
example shown in Rg. 18), is not propagated while 
the query sent to another DSU is propagated (DSU 

50 C), resulting in the response from one DSU arriving 
very much before the response from the other. 
Incorrect operation may result if the source DSU 
responds to the user and erases any m mory of 
the query immediately after the first response. 

55 
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Secondly, there is the possibility that query 
messages may 'loop'. For example In Rgure 19, 
th P-tables are set up so that DSU A sends 
queries to DSU B, and DSU B send qu ries to DSU 
C. If no mechanism was in place to prevent loop- s 
ing. queries could t)ounce back and forth between 
the two DSUs forever. 

The mechanism that will t>e described in the 
following sections solves the above problems by 
aeating a special control block for each query and io 
maintaining that control block untirpropagation has 
terminated. Further details are discussed below 
under "The Basic Query Propagation Mechanism". 



P-Tables 

The P-tables at the various DSUs define how 
the DSUs Interact with one another in performing 
queries. Each DSU In the networic contains P-tables 20 
for every directory type for which it may perform 
undirected queries. The P-table in a DSU contains 
the identities of some of the other DSUs in the 
network. It must be possible to establish a commu- 
nication path with any DSU that appears in a P- 2S 
table. 

The P-table consists of two parts, a query P- 
table (QP-tabie) and an update P-table (UP-table). 
Additional description of the function and use of the 
update P-tables is contained in the above-referen- so 
ced copending application (A3). Additional descrip- 
tion of the directory control block and the query 
control *block used in query propagation is con- 
tained in the atx)ve-referenced copending applica- 
tion (A2). The QP-table defines the DSUs to which 35 
queries are sent. The structure of the tables is 
shown in Figure 20. In addition to containing the 
identities of the DSUs these tables define the order 
in which the DSUs are queried, by specifying a 
numeric parameter or priority associated with each 40 
DSU. The DSU wrtii the highest priority is sent the 
query message first, while DSUs with equal priority 
recent tiie messages in parallel. As Rgure 20 also 
depicts, there is an extra algorithm control field 
assodated with each DSU entry. 45 

The following describes the processing of que- 
ries and updates, with or without propagation. The 
different cases involved in such processing include: 

Query Processing at tt^e origin DSU witiiout 
propagation -the origin DSU receiving the query so 
request from the user satisfies the request from tiie 
locally residing directory without propagation. 

Query Proc ssing at tiie origin DSU witii prop- 
agation. Th origin DSU cannot locally satisfy the 
requ st from th user and, therefore, originat s the 55 
query r quest for propagation to other r mot 
DSUs. 



Query Processing at the intermedial DSU - 
The int rmediate DSU receiving a query request 
from th remote DSU cannot satisfy the requ st 
and, therefore, propagates the query request fur- 
tfier to other DSUs. 

Query Processing at tiie target DSU -The tar- 
get DSU receiving a query request retrieves the 
requested data and send the query reply toward 
ttie origin DSU. 

Update Processing at tiie origin DSU -The ori- 
gin DSU receiving an update request from tiie user 
originates the update request for the propagation to 
tiie DSUs to be affected. 

Update Processing at tiie intermediate DSU - 
The Intermediate DSU receiving an update request 
from the remote DSU propagates the update re- 
quest furtiier to other DSUs to be affected. 

Each case will be descrit)ed separately by con* 
sidering only those components of the directory 
system, structure that are required to process tfie 
given case. In the drawings, solid lines with arrows 
denote procedure CALLS. Dotted lines witii arrows 
denote the execution of the protocol boundaries or 
tiie access of the control data block. Figure 14 
illustrates the directory system model for the query 
processing, while Rgure 13 illustrates the directory 
system model for update processing. 



QUERY PROCESSING CASES 

Query Processing at Origin DSU (No propagation) 

Tlie processing steps include: 

1. The application program calls the API_ 
Query Send Processor to pass ttie QUERY verb. 

2. The API__ Query^ Send validates its 
syntax and parameters. The API_ Query_ Send 
calls the DSI_Query_RQ processor to pass the 
Query request for processing, 

3. The DSI_ Query_ RQ processor calls 
tiie Data__Read processor to request the data. The 
Data^Read processor retrieves tiie requested di- 
rectory data by managing the data access protocol 
boundary according to ttie directory descriptors, 
and returns the retrieved data to the 
DSI_Query__RQ. 

4. The DSI_Query_RQ constucts tiie DSI 
query reply which carries the ret-ieved data, and 
calls the DSI_Query_Reply processor to pass the 
query reply. 

5. The DSl_Query_Reply processor man- 
ag s th finit stat machines associated with tii 
qu ry request and calls the API_Query_R ply 
proc ssor to pr s nt th results of the qu ry to the 
application program. 
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6. The API Query Reply Processor de- 
codes the DSI query reply and places the resulting 
data Into th queue. 

Control is ventually returned to the - 
API_Query__Send. At this time. the 5 

API Query ^Send returns control with the return 

code ("successful") to the appilcation program. 



Query Processing at the origin DSU (Propagation) io 

The processing for the case where the origin 
DSU cannot satisfy the query request from the 
local directory, thus originating the DSI query re- 
quest for propagation to other remote DSUs. is as 75 
follows: 

1. The application program calls the 
API_Query_Send Processor to pass the QUERY 
verb. 

2. The API_Query_Send validates its syn- 20 
tax and paramemeters ters. The 
API_Query_Send calls the DSI_Query_RQ pro- 
cessor to pass the Query request for processing. 

3. The DSI_Query_RQ processor calls the 
Data^Read processor to request the data The 25 
Data^Read processor returns an indication that it 
cannot find the requested data from the local direc- 
tory. 

4. The DSI_^Query_RQ calls the Query Al- 
gorithm which is one of the Directory alogorithm so 
fadlitles. The query algorithm determines which 
DSU to send the DSI query request to for remote 
search. 

5. The DSI__Query_RQ places the destina- 
tion DSU name (which indicates the next DSU for 35 
the request to be delivered to) in the appropriate 
field of the DSI query request, and calls the 
Data^Send processor to send the DSI query re- 
quest through the network. 

6. The Data__Send processor manages the 40 
network protocol boundary for proper delivery of 

tiie DSI query request to the destination DSU. At 
this time control will be returned to the 
API_Query_Send through the DSl_Query_RQ. 
and API_Query_Send returns control with the re- 45 
turn code ("successful") to the application pro- 
gram. 

7. The Data^Receive processor receives 
the DSI query reply canning the requested data 
from the remote DSU through the network protocol so 
boundary. 

8. The Data_Receive processor calls the 
DSI_Query_Reply processor to pass the DSI 
query reply received from th remote DSU, 

9. The DSl_Query_Reply processor man- 55 
ages the finite state machines associated with the 
query request, and calls the API_Query_Repiy 
processor to present the results of the query to the 



application program. Optionally, the results of the 
query can be retained in the local directory by 
cailing the Data^Write processor. 

10. Th API_Query_Reply Processor de- 
codes the DSI query reply and places the results of 
the query into the queue. Optionally, application 
program is scheduled for each enqueued query 
result 



Query Processing at an Intermediate DSU 

The processing for the case where the inter- 
mediate DSU receives a DSI query request but it 
cannot service the query request from the local 
directory, thus sending the DSI query request for 
propagation to other remote DSUs, is as follows: 

Processing steps: 

1. The Data__Recelve processor receives 
the DSI query request from the remote DSU 
through the network protocol boundary. 

2. The Data_Receive processor calls the 
DSI Query RQ processor to pass the DSI query 
request received from the remote DSU. 

3. The DSI_Query_RQ processor calls the 
Data_Read processor to request for the data. The 
Data_^Read processor returns an indication that It 
cannot find the requested data from the local direc- 
tory- 

4. The DSI_Query_RQ calls the Query Al- 
gorithm to determine which is the next DSU for 
query propagation. 

5. The DS!_Query_RQ places the destina- 
tion DSU name in the appropriate field of the DSI 
query request, and calls the Dala_Send processor 
to send the DSI query request through the networic. 

6. The Data__Send processor manages the 
network protocol boundary for proper delivery of 
the DSI query request to the destination DSU. 



Query Processing at Target DSU 

The processing for the case where the target 
DSU receives a DSI query request from a remote 
DSU, retrieves the requested data from the local 
directory and sends the DSI query reply toward the 
origin DSU is as follows: 

Processing steps: 

1. The Data^Receive processor receives 
the DSI query request from the remote DSU 
through the network protocol t)oundary. 

2. The Data_R ceive processor calls the 
DS!_Query_RQ processor to pass the DSI query 
request r ceived from remote DSU. 

3. The DSI_Query__RQ processor calls the 

Data Read processor to request for th data. The 

Data_Read proc ssor retrieves th r quested di- 
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rectory data by managing the data access protocol 
boundary according to the directory descriptors, 
and r turns the retri v d data to the 
DSI_Query_RQ. 

4, Th DSl_Query_RQ constructs the DSI 
query reply which carries the retrieved data, and 
calls the Data_Send processor to send the DSI 
query request through the network. 

5. The Data^Send processor manages the 
network protocol boundary for proper delivery of 
the DSI query request to the destination DSU. 



Creadon of P-Tables 

The entries in each P-table may be created in 
several different ways. They may be linked directly 
to the way in which data is distributed through the 
system, something which may be specified in the 
form of an affinity table. 

Alternatively, the P-tables may be defined di- 
rectly at system generation time and remain un- 
changed through the entire directory operation tion. 
or may be updated dynamically. They may also be 
created during operation or through other mecha- 
nisms such as queries to a 'directory of directories' 
or through input from the network routing function. 

Access of P-Tables 

Furthemnore, the protocol boundary may permit 
only indirect access to the P-tables. The indirection 
is in that the user does not specify the actual 
entries in the P-tables. but, instead, specifies the 
way in which he wants data distributed through the 
network using certain data distribution primitives. 
These notions are then translated automatically into 
entries in P-tables. 

The advantage of this indirect approach is that 
It enables the user to think of the directory struc- 
ture only in terms of data distribution, something 
that is intuitive and easy to understand, while 
shielding him from the complexities of understan- 
ting the flow of queries. The disadvantage of tiiis 
approach is that it limits flexibility and prevents the 
user from exercising the full range of query propa- 
gation options that is possible if direct access to 
the P-tables is permitted. 



DATA DISTRIBUTION PRIMITIVES 

The user may defin som data distribution 
relationships between the DSUs in the network. 

5 This section describes the relationships, how they 
are used to set up a directory service system, and 
how these relationships tiien get translated into P- 
table enties. 

In understanting tfie motivlation behind the 

10 translation, it is important to understand ttie 
"duality" between queries. In particular, if DSU A 
always sends an update to DSU B whenever it 
changes its directory, there is no necessity for DSU 
B to ever query DSU A. Conversely, if DSU B 

J5 always queries DSU A, there is no necessity for 
DSU A ever to send updates to DSU B. The 
translation from data distribution to P-table entries 
is designed to take this "duality" into account and 
thus to conserve on the use of communication 

20 t>andwidth. 

The relationships are with respect to a specific 
directory type ID. It is possible and indeed likely 
that the relationship for different directory type ID's 
will be quite different The following data disti'ibu- 

25 tion relationships can be defined: 



Sup-Sub Relationship 

00 The superior (SUP)-subordinatB (SUB) relation- 
ship is depicted pictorially in Rg. 21 by a directed 
arc from A to B. A is the SUB and B is ttie SUP. 
The relationship is established by specifying at A 
that B is a SUP of A and by spedfying at B ttiat A 

35 is a SUB of B. TTits relationship implies that under 
"normal" conditions a communication path exists 
from the SUB to ttie SUP tfirough tiie transport 
mechanism. In terms of data distribution, it implies 
ttiat if X is ttie directory type ID for which ttits 

40 relationship has been defined, ttien B's directory of 
type ID X is a superset of A's directory of the same 
type ID. 

The translation into P-tabie entries attempts to 
preserve the nature of the relationship. As B is ttie 
45 SUP of A. both queries are propagated from A to 
B. However, as B's directory contains all ttie in- 
fonnation that A's directory contains. B neither que- 
ries nor updates A. The translation to P-table en- 
tries in A and B is depicted in Figure 22. 

5a 

Peer-Peer Relationship 

As shown in Rg. 23. this relationship is de- 
55 picted pictorially by an undirected arc b tween tti 
PEERS. The relationship is established by specify- 
ing at A ttiat B is a PEER of A and by specifying at 
B ttiat A is a PEER of B. This relationship implies 
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that the PEERs can communicate with each other 
through the transport m chanism and that the user 
would like them to communicat directly in order to 
perform directory functions, it does not Imply any 
relationship in terms of data distribution. Thus, in 5 
the translation to P-table entries, queries are ex- 
changed between PEERs, as represented in Rg. 
24. 

70 

Replicated Relationship 

This relationship is depicted pictorially in Fig. 
25 by a bidirectiona) arc between the OSUs. The 
relationship is set-up by specifying at A that B is a 75 
REPUCATE of A and by specifying at B that A is a 
REPLICATE of B. This relationship implies that the 
DSUs can communicate with each other through 
the transport mechanism. In tenns of data distribu- 
tion, it is equivalent to two SUP-SUB relationships; 20 
that is, B is a superset of A and A Is a superset of 
B. Clearly, this can be satisfied only if A and B are 
identical. The translation to P-table entries is de- 
signed to preserve the repiication by propagation 
updates between the DSUs as represented in Rg 25 
26. It will be apparent that many other types of 
relationships are possible. 



Other Relationships 30 

The examples shown in Rgs. 27-30 illustrate 
that the definition of relationships between the 
DSUs in a network detenmines the data distribution. 
It will be noted that the relationships define a 
network over which queries are normally propa- 
gated. 'Hiis network is usually a sub-network of the 
network formed by defining all possible commu- 
nication paths. In other words, there may be com- 
munication paths available between DSUs which 4o 
are not normally used In query propagation. 



PRIORITIES OF THE ENTRIES 

45 

It has been shown how the data distribution 
primitives defined get mapped into entries in the 
QP-table and the UP-table. It needs to be shown 
how the priority of these entries is established. 
Consider tiie UP-table. Clearly, it is advantageous so 
to propagate in parallel to all SUP DSUs, as this 
would enable the update to reach the appropriate 
d stinations as soon as possibi . Thus, in the 
translation to P-table entries, all entries are given 
equal weight as shown as an example in Rg. 31 . 55 



Considering the QP-table. both SUPs and 
PEERS are entered into the table. In propagating 
queries, it is not the case that parallel propagation 
is always desirable. In some instances, sequential 
propagation may be preferable as it may result in 
less bandwith being used in query propagation. 
Thus, two basic metiiods. the parallel and the se- 
quential, are provided for in constructing P-tables. 
The choice of parallel or sequential can be con- 
trolled at the time of system definition. 

The parallel approach is very similar to that 
used in the construction of tiie UP-tables. All SUP 
entries are given equal priority and all PEER en- 
tries are given equal priority. The priority of the 
SUPs, however, is higher than tfie priority of tiie 
PEERs (that is. a smaller numerical value). For 
reasons that will become apparent when tiie al- 
gorithms are described, the SUPs are assigned a 
negative number as priority. Rg. 32 shows an 
exarnple of this. 

This sequential propagation approach assigns 
priority number to the DSUs in ascending order, 
with tiie SUPs having tiie smaller numbers, (again 
chosen to be negative), and tiie PEER'S tiie larger 
number (positive). Rg. 33 depicts tiiis tiirough an 
example. 

The detemaination of whetiier parallel or se- 
quential propagation Is used is usually made at 
create-configuration time or automatically by 
means of a predefined user algorithm. It is impor- 
tant that all tiie DSUs that participate in a given 
query use the same mode of propagation. Thus, it 
is not permitted for the originating node to propa- 
gate a query in a sequential fashion and for inter- 
mediary nodes to relay that query in parallel fash- 
ion. In order to ensure this, the query messages 
that are propagated in the network contain a bit 
which indicates whether the DSU that initiated tfie 
query used sequential or parallel propagation. 

Intermediary nodes use the method of propa- 
gation indicated in the query message, thereby 
ignoring tiie priorities in the QP-table, and creating 
a new set of priorities if the query message speci- 
fies a different mode of propagation than tiie mode 
for which their QP-tables are set up. 



RELATIONSHIP RULES 

The relationships of tiie DSUs in the networic 
for a given directory type ID should satisfy certain 
njles. These njles are important in order to main- 
tain intemal consistency of the P-tabI in a given 
DSU. as well as in tiie relationship between P- 
tables in different DSUs. The rules are as follows: 
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2. There exists a DSU C so that there are 
paths consisting entir ly of directed arcs, traversed 
In the indicated direction, from both A and B to C. 
Note that a d generat case where this condition 
would be satisfied would be if there was a directed 5 
path from A to B or vice versa. 

In order for the propagation algorithms not to 
use an unecessarily large amount of bandwidth, 
only one of 1 and 2 above must hold. 

If B is PEER(A), then D cannot be SUP(A) or w 
REPLICATE(A). Similary. if B is SUP(A)» then B 
cannot be PEER(A) or REPLICATE(A); and 

PEER relationships are always reciprocal. Simi- 
larly, if B is SUP(A) then B cannot be PEER(A) or 
REPUCATE(A) and if B = REPUCATE (A) then it is 
cannot be PEER(B) or SUP(A). 



THE BASIC QUERY PROPAGATION MECHANISM 

20 

This is shown in block diagram form in Fig. 14. 
The query message sent between the DSUs con- 
tains all the information that initiated the query, and 
in addition, the identification of the DSU that origi- 
nated the propagation of the query (the source 25 
DSU). and a correlation numt^er which is generated 
by the source DSU. Rg. 34 shows a typical query 
message. Any response message contains the in- 
formation generated in response to the query and. 
importantly, also includes the identification of the 30 
DSU that was the source of the query and the 
correlation number contained in the query. Fig. 35 
shows a typical query response message. 

The combination of source DSU identification 
and correlation number is used by the various 3S 
DSUs in the network to uniquely identify that query 
and to correlate responses to the query with the 
query itself. The DSU identities are required to be 
unique. In order for the combined DSU identity 
plus con-eiation number to be unique, it is neces- 40 
sary for the source DSU to ensure that it uses a 
congelation number only if it is certain that no 
instance of any previous query message that it 
may have generated with the same conrelation 
number remains in the networic. 45 

A practical method of achieving this is to use 
as a correlation number a time-stamp or a con- 
stantly incremented sequence number, taking care 
to ensure that the size of the correlation number 
field and therefore, the time t>etween wrapping of so 
the number, is large. The propagation of query 
messages is guided by the P-tables for ttiat direc- 
tory type at each DSU. 



SUMMARY 

It has beeen successfully demonstrat d tinat 
qu ries can b propagated across any ndtwortc 
environment or topology. Either theses queries can 
be directed to a target or undirected (automatic) by 
means of the use of P-tables. 

P-tables define relationships (SUP-SUB. PEER- 
PEER, etc.) between directory units (DSUs). wheth- 
er they are local or remote. Based on priority and 
the type of propagation desired (sequential or par- 
allel), queries are sent to participating DSUs. In 
addition, the mechanisms also provide for the user 
to specify his own algoritiims to eHher propagate 
queries or determine the mode. The mechanisms 
thus described provide for both uni-and bi-direc- 
tional query propagation. Inherent in these mecha- 
nisms is the performance criteria to reduce kx)ping 
and audit trails for recovery. 



Claims 

1. In a directory database system including a 
network having a plurality of communication paths 
and a plurality of directory service units (DSU), 
each of said DSUs providing one or more directory 
service functions within said directory database, an 
apparatus for propagating a user query relative to 
an object from a source DSU to a target DSU 
comprising : 

a special directory containing the identities of tar- 
get DSU's for certain of said objects in said net- 
work, 

means for communicating said user query from 
said source DSU to said special directory means 
for generating information identifying tiie target 
DSU for said object embodied in said query, and 

means for communicating said information relative 
to said identified target DSU to said source DSU. 

2. In a directory database system including a > 
network having a plurality of communication paths 
and a plurality of directory service units (DSU). 
each of said DSUs providing one or more directory 
service functions within said directory database, an 
apparatus for propagation of an undirected user 
query relative to an object from a source DSU to 
one or more target DSUs, which target DSU may 
contain information relative to said object, compris- 
ing : 

- a propagation (P) table in each of said DSUs. 
ach of said P tables t>eing a data structure ca- 
pabl of d t rmining which otiier DSU's to send 
said user qu ry to, 
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-means in said source DSU for examining its asso- 
ciated P table for the directory type specified in 
said query to generate an identification of one or 
mor . additional target ones of said DSUs to which 
said query should be directed, s 

-means for propagating a query from said source 
DSU to those additionaJ DSU's identified by said P 
table in said source DSU, and 

10 

-means for returning to said source DSU informa- 
tion responsive to said user query from the one of 
said additional target DSU's containing said in- 
formation. 

3. Apparatus in accordance with Claim 2 in- 75 
eluding means in each of said additional DSU*s for 
examining its P table to detenmine the Identity of . 
the target DSU to which said query should be 
directed. 

4. Apparatus In accordance with Claim 2 in 20 
which each of said P tables includes a query P- 
table (QP-table) and an update P-table (UP-table). 

S^paratus in accordance with Claim 4 in 
which said QP table defines the one or more target 
DSUs to which a query should be sent. 2S 

6. Apparatus in accordance with Claim 5 in 
which each of said QP tables contain information 
determining the order in which any additional target 
DSUs are to be queried. 

7. Apparatus in accordance with Claim 4 in 30 
which each of said QP tables in each particular one 

of said DSUs defines the status relationship of said 
particular DSU to other DSUs of the same directory 
type. 

8. Apparatus In accordance with Claim 7 in 35 
which the QP table in said particular DSU defines a 
superior-suixjrdinate relationship t>etween said par- 
ticular DSU and one or more of said other DSUs. 



9. Apparatus in accordance with Claim 7 in 
which the QP table in said particular DSU defines a 
peer-pe r relationship between said particular DSU 
and one or mor of said other DSUs. 

10. Apparatus in accordance with Claim 7 in 
which the QP table in said particular DSU defines a 
replicated relationship between said particular DSU 
and one or more of said other DSU's. 

11. Apparatus in accordance with Claim 5 in 
which each of said QP tables detennines whether 
further propagation of a query to a plurality of other 
DSU's is to be In a serial or a parallel mode. 

12. Directory service system having a plurality 
of interconnectable. directory service units (DSU). 
characterized in that it comprises a plurality of 
processes within said directory service system, 
said plurality of processes including: 

-a P(U) process for interfacing with a user of said 
system at a user protocol boundary; 

-a P{D) process for interacting with a directory 
database at a directory data access protocol 
boundary; 

•a P(N) process for Interacting with a communica- 
tion network at a network control boundary; and 

-a P(F) process for interacting with at least one of 
the other of said processes in said directory ser- 
vice system. 

13. Directory service system in accordance 
with Claim 12 in which each of said processes is 
located in one of said DSUs. 

14. Directory service system in accordance with 
Claim 13 in which said directory database witti 
which said P(D) process interacts is accessible by 
said P(D) process from the one of said DSUs in 
which said P(D) process is located. 
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